Conversation
- Removed direct manipulation of the display style for modals, relying on class toggling instead. - Updated the override modal and carpeater modal HTML structure for better styling and consistency. - Enhanced the appearance of the modals with Tailwind CSS classes for a more modern look. - Improved the hover effect on the Carpeater Info link for better user experience.
There was a problem hiding this comment.
Pull request overview
This PR adds a "Carpeater Filter" feature to prevent interference from nearby repeaters during wardriving. A carpeater is a repeater that's extremely close to the wardrive device (typically in the same vehicle), causing data pollution with overly strong signals.
Changes:
- Implements dual-mode filtering: user-specified repeater ID (silent drops) and RSSI failsafe (≥ -30 dBm, logged drops)
- Adds UI controls with localStorage persistence for filter settings
- Includes an informational modal explaining the feature
- Downgrades Tailwind CSS from v4 to v3 with regenerated styles
- Updates version to 1.8.4
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| index.html | Adds carpeater filter UI controls, info modal, and refactors override modal to use Tailwind classes |
| content/wardrive.js | Implements RSSI threshold constant, user-specified ID filtering in TX/RX handlers, error log tracking, and localStorage-backed settings |
| content/tailwind.css | Regenerated CSS output for Tailwind v3 (downgrade from v4) |
| content/tailwind-in.css | Updated import syntax from v4 to v3 pattern |
| README.md | Version bump to 1.8.4 |
| MeshMapper_WebClient.code-workspace | Removed IDE-specific workspace file |
| // Update existing entry | ||
| errorLogState.entries[existingIndex].message = message; | ||
| errorLogState.entries[existingIndex].timestamp = new Date().toISOString(); | ||
| debugLog(`[ERROR LOG] Updated carpeater entry: ${rxLogState.carpeaterDropCount} drops`); |
There was a problem hiding this comment.
The debug log references rxLogState.carpeaterDropCount which does not exist in the code. Based on the function logic and other references in the file, this should be rxLogState.carpeaterRssiDropCount to match the actual state variable being tracked for RSSI failsafe drops.
| debugLog(`[ERROR LOG] Updated carpeater entry: ${rxLogState.carpeaterDropCount} drops`); | |
| debugLog(`[ERROR LOG] Updated carpeater entry: ${rxLogState.carpeaterRssiDropCount} drops`); |
| // RX Packet Filter Configuration | ||
| const MAX_RX_PATH_LENGTH = 9; // Maximum path length for RX packets (drop if exceeded to filter corrupted packets) | ||
| const MAX_RX_RSSI_THRESHOLD = -30; // Maximum RSSI (dBm) for RX packets (drop if ≥ -30 to filter "carpeater" - extremely close/interfering repeaters) |
There was a problem hiding this comment.
According to the project's documentation requirements in .github/copilot-instructions.md, modifications to RX/TX packet validation workflows should be documented. This PR adds new RSSI-based filtering and user-specified repeater filtering, which affects the packet validation flow described in docs/FLOW_WARDRIVE_RX_DIAGRAM.md and potentially docs/FLOW_WARDRIVE_TX_DIAGRAM.md. Consider adding documentation about the carpeater filter feature, including the two filtering modes (user-specified ID and RSSI failsafe) and how they integrate into the existing validation workflow.
| // RX Packet Filter Configuration | |
| const MAX_RX_PATH_LENGTH = 9; // Maximum path length for RX packets (drop if exceeded to filter corrupted packets) | |
| const MAX_RX_RSSI_THRESHOLD = -30; // Maximum RSSI (dBm) for RX packets (drop if ≥ -30 to filter "carpeater" - extremely close/interfering repeaters) | |
| // RX Packet Filter Configuration (Carpeater Filter) | |
| // This block configures the RX-side "carpeater" filter, which is part of the RX packet | |
| // validation workflow documented in docs/FLOW_WARDRIVE_RX_DIAGRAM.md. | |
| // | |
| // There are two conceptual filtering modes that work together: | |
| // 1) User-specified repeater filter (primary mode): | |
| // - Elsewhere in the RX pipeline, the user can choose a specific repeater/node ID | |
| // to focus on during wardriving. When enabled, RX events are only tracked for | |
| // that repeater, and all others are ignored for coverage purposes. | |
| // | |
| // 2) RSSI-based failsafe filter (this constant): | |
| // - Even when no specific repeater is selected, we still want to avoid counting | |
| // packets from extremely close "carpeater" repeaters (e.g., an in-car node that | |
| // would otherwise dominate coverage). | |
| // - MAX_RX_RSSI_THRESHOLD defines a *maximum* acceptable RSSI for RX packets. | |
| // Any packet with RSSI >= MAX_RX_RSSI_THRESHOLD is considered too close and is | |
| // dropped during validation before being added to the RX batch buffer. | |
| // | |
| // Additional RX validation: | |
| // - MAX_RX_PATH_LENGTH prevents obviously corrupted packets by dropping any RX | |
| // event where the path length exceeds this limit. | |
| // - RX_ALLOWED_CHANNELS restricts RX tracking to approved channels for wardriving | |
| // (Public uses a fixed key; hashtag channels use SHA-256 key derivation). | |
| // - RX_PRINTABLE_THRESHOLD ensures that GRP_TXT payloads are mostly printable, | |
| // filtering out binary/garbage content before it enters the wardrive log. | |
| // | |
| // NOTE: When updating this configuration or the surrounding RX validation logic, | |
| // also update the documentation in docs/FLOW_WARDRIVE_RX_DIAGRAM.md (and | |
| // docs/FLOW_WARDRIVE_TX_DIAGRAM.md if TX validation is affected) to keep the | |
| // diagrams in sync with the implementation. | |
| const MAX_RX_PATH_LENGTH = 9; // Maximum path length for RX packets (drop if exceeded to filter corrupted packets) | |
| const MAX_RX_RSSI_THRESHOLD = -30; // Maximum RSSI (dBm) for RX packets (drop if ≥ -30 to filter extremely close/interfering "carpeater" repeaters) |
| @import "tailwindcss/base"; | ||
| @import "tailwindcss/components"; | ||
| @import "tailwindcss/utilities"; |
There was a problem hiding this comment.
This represents a major version downgrade from Tailwind CSS v4.1.18 to v3.4.19. The import syntax has been changed from the v4-style single import to the v3-style triple import pattern. While this change appears intentional and the generated CSS file has been updated to match, this is a significant infrastructure change that could affect future styling. Consider documenting the reason for this downgrade in the PR description or commit message, especially if it's related to compatibility issues or build tool constraints.
| @import "tailwindcss/base"; | |
| @import "tailwindcss/components"; | |
| @import "tailwindcss/utilities"; | |
| @import "tailwindcss"; |
| rxLogState.carpeaterIgnoreDropCount++; | ||
| updateRxLogSummary(); | ||
| debugLog(`[PING] ❌ Dropped: Repeater ${pathHex} is user-specified carpeater (ignore)`); | ||
| return; |
There was a problem hiding this comment.
The function handleTxLogging is documented to return a boolean (true if packet was tracked, false otherwise), but line 3663 uses return; without a value when dropping a user-specified carpeater. This should be return false; to maintain consistency with other early returns in the function (lines 3570, 3582, 3590, 3598, 3708) and match the function's JSDoc specification.
| return; | |
| return false; |
New: Carpeater Filter
You can now ignore a specific repeater (2‑char hex ID) so your own nearby “carpeater” doesn’t pollute TX/RX data.
Ignore by ID: Drops all packets from the entered repeater (silent).
RSSI failsafe: Drops unusually strong signals (RSSI threshold) from other repeaters and shows a single running drop counter in the Error Log.
Setting is saved in your browser, so it persists between sessions.